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ABSTRACT 


lii a distributed system where many processors are connected by a network and 
communicate using message passing, many users can be allowed to access the same facilities. 
A public utility is usually an expensive or limited resource whose use has to be regulated. 
A guardian is an abstraction that can be used to regulate the use of resources by 


scheduling their access, providing protection, and implementing recovery from hardware 
failures. We present a language construct called a primitive serializer which can be used 
to express efficient implementations of guardians in a modular fashion. We have developed 
a proof methodology for proving strong properties of network utilities e.g. the utility is 
guaranteed to respond to each request which it is sent This proof methodology is 
illustrated by proving properties of a guardian which manages two hardcopy printing 


devices. 
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I ~ INTRODUCTION 


1.1 — Semantics 

Programs written for distributed systems with many processors can be plagued by 
subtle errors arising in unpredictable situations. To limit these problems, it is necessary 
that the primitives for dealing with concurrency provided by our programming languages 
have simple intuitive interpretations and completely unambiguous definitions. They should 
also be powerful enough to express simple solutions to simple or common problems and to 
admit rigorous proof methods. For both of these reasons we have been looking for 
primitives whose semantics are mathematically well defined. We want each primitive 
construct to denote a mathematical object which defines the behavior of the primitive. 
Our methods of proof are ultimately based on theorems about these mathematical objects. 

In a similar vein mathematical semantics must be provided for any well defined 
specification language. Ideally a specification language should be powerful enough so that 
it is convenient to express both the partial specifications of the abstractions of the user 
(such as airline reservation systems and disk head schedulers) as well as the abstractions of 
the programming language (such as monitors and serializers). 

This paper makes use of a description system in which the properties of actors 
can be described. A distinctive feature of our description system is that it specifies the 
required behavior of objects rather than their physical representation. Instead of using 
predicates to state the interface recjuirements between modules, descriptions are attached to 
the data manipulated by each module. The idea is to allow properties of actors to be 
specified in the form of descriptions that appear directly in the code 


L2 — Guardians 

Guardians are abstractions that can regulate the use of a resource by scheduling 

its access, providing protection, and implementing recovery from hardware failures which 

manifest themselves as time-outs. In this paper we develop partial specifications and proofs 

for an hardcopy server for two printing devices. In a subsequent paper we will present 

partial specifications and proofs for other guardians such as a readers-writers guardians 

using different scheduling algorithms, a guardian for a disk spindle that optimizes head 
motion, etc. 
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1.3 — Primitive Serializers 

The guardians in this paper are implemented using primitive serializers which are a 
further development of serializers {Hewitt and Atkinson: 1977, 1979]. Primitive serializers 
are more flexible than previous serializers in that they have less built-in machinery. Their 
more primitive character gives them the ability to efficiently implement the facilities (such 
as queues) that were provided by previous serializers as well as to implement new facilities 

that were not provided before. 

Unlike previous serializers, primitive serializers do not have any implicit 
nondeterminism in the evaluation of synchronization conditions. Additional flexibility 
comes form the fact that primitive serializers can explicitly deal with actors which act as 
customers to whom replies should be sent. Our notion of a customer is a generalization of 
the notion of a continuation to deal with the issues of concurrency, protection, and 
interrupts. Customers can be dealt with as any other actors. For instance they can be 
put into queues for implementing scheduling policies. 

At the same time primitive serializers maintain the advantages of serializers over 
other published proposals for synchronization primitives such as monitors [Hoare; 1974; 
Brinch-Hansen: 1973] and Communicating Sequential Processes [Hoare: 1978]. The examples 
considered in this paper are used to illustrate the advantages of using the actor model for 
partially specifying and proving properties of guardians. 
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II - A DESCRIPTION SYSTEM 


II. 1 — Goals 

The main goal of our description system is to conveniently use the following kinds 
of descriptions: ’ 

PARTIAL descriptions are used to express whatever properties of an object 
happen to be known at particular point in time if they are incomplete. Partial descriptions 
are important in partial specifications because it is impossible to arrive at complete 
specifications for a large software system all at once. They are important in proofs because 
in a proof some properties are given whereas others must be derived. 

* s 

INCREMENTAL descriptions which enable us to further describe objects when 
more information becomes available and are a necessary feature for the use of partial 
descriptions. Incremental descriptions are important in proofs and incremental 
specifications because all of the properties are not available at one time but must be 
derived and evolved with time. 

MULTIPLE descriptions which enable us to ascribe multiple overlapping 

descriptions to an object which is used for multiple purposes. Multiple descriptions are 
important in multiple specifications and proofs because different properties of an object 
might be useful in different contexts. 

We would like to point out the usefulness of description systems to describe partial 
specifications for programs. In fact the assumptions and the constraints on the objects 

manipulated by a program are an integral part of the program and can be used both as 
checks when the programming is running and as useful information which can be exploited 
J ^ t' ^ Iii r li examine the program such as translators, optimizers, indexers, etc. 

We believe that bugs occurring in programs are frequently caused by the violation of 

implicit assumptions about the environment in which the program is intended to operate. 
Therefore many advantages can be drawn by a system that encourages the programmer to 
state such assumptions explicitly, and by a system which is able to detect when they are 
violated. 

The fundamental axiom of our description system can be stated as follows: 
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if (description^ is <description 2 » and (<description 2 > /s <description 3 » 
then ^description j> is Xdescriptionj)) 

and is called the Axiom of Transitivity of Predication. It implies that inheritance holds 
in our description system and that all descriptions are organized in a large tangled 
hierarchy in some ways similar to the ones in Roget's Thesaurus and the Micropaedia of 
the Encyclopedia Britannica. 

Our description system is designed to allow us to provide multiple partial 
descriptions of objects. For example (a Cartesian_complex [imaginary _part: 0]) is a description of 
an instance of a Cartesian complex number whose imaginary_part is 0. Note that we have 
used the indefinite article "a" to mark descriptions of instances of a concept Descriptions 
can in turn be multiply described. For example the following command describes 
(a Cartesian.complex) as being (a Number) and as having two attributes, namely a reaLpart and 
an imaginary_part each of which must be a Real. 


The description below says that a Cartesian_complex is a Number: 

((a Cartesiajvcomplex) /$ (a Number)) 

A Carte$ian_compl©x can be further described as follows: 

((a Cartesian.complex) is [a Cartesian_comp!ex [real_part: (a Real)] [imaginary _parh (a Real)])) 

* . ' . 

Note that by using the concept Cartesian.complex twice in the above description that we have 
specified that every Cartesian_complex has two attributes realjpart and imaginaryj^art which each 

have as value a Real. 

< ■ ■ ..■■■■■ • ■ 

Note that the is statement is asymmetric so that it would be incorrect to say 


(a Cartesian_complex)/S (a Real) 

since a Cartesian complex number is not always a real number. Furthermore it would also 
be incorrect to say 

(a Cartesian_complex) /S-i(a Real) 
since some Cartesian complex numbers are Real. 
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Our description system successfully deals with an important distinction that has 
plagued most previous systems which rely on inheritance. Given that 3+4i is a 
Cartesian_complex and that Cartesian_complex is an Algebraicjield, one IS not allowed to conclude 
that 3+4i is an AlgebraicJield. Note that this mistake will not occur in our system because 
the rule of transitivity of predication does not apply to the following two descriptions-' 

3+4i is (a Cartesian_complex) 


Cartesian_comp!ex IS (an Algebraicjield) 


While Cartesian_complex is described as being an Algebraic field, an instance of Cart®sian_complex 
such as (a Cartesian.complex) cannot be considered as an Algebraic field. Logicians as long ago 
as Aristotle have known that Cartesian_comp!ex must not be confused with (a Cartesian.complex). 
However, a good notation was lacking in which to axiomatize the difference 


The user can describe a Real x as being a Cartesian_complex with real_part x. and 
imaginary part 0; 


((a Real) whichjs =x) is (a Cartesian_complex [real_part: =x] [imaginary_part: 0]) 

The character = is used to mark local identifiers. Local identifiers play a role in the 
description system similar to the role played by free identifiers in formulas in the 
quantificationa! calculus: they can be bound to any object. For example since 

(3 is (a Real)) 

it follows that 

(3 is (a Cartesian_complex [real_part: 3] [imaginary_part: 0])) 


The user can partially describe a Carter, ian_complex 
as being x wdiich is a Real: 


with real_part x 



imaginary_part 0 


((a Cartesian_complex [real_part: =x] [imaginary.part: 0]) which_is =x) is (a Real) 

Notice that we have just established a mutual dependency among our descriptions because 
we have described Real in terms of Cartesian.complex and vice versa. This will enable us to 
view either one as the other in the appropriate circumstances. 
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The above descriptions express some of the relations between Real and 
Cartesian_complex numbers. We believe that it is important that a description system allows 
information to be presented in an incremental fashion. For example it should be possible 
for the user to later further describe Cartesian.complex numbers relative to other kind of 

numbers. 

(3 Cartesian_complex [real_part: =x] [imaginary _part: =y]) is 
(a Number) and 

(a Polar_complex [magnitude: =r (a Real)]) 
such_that 

(r is (x^ + y^)^ I 

It is important to realize that in giving the above descriptions the user is not 
making any commitments as to the physical representation of complex numbers. The 
possibility is still open that complex numbers will be physically represented in Cartesian, 
Polar form, some mixture, or still some other alternative physical representation. It is even 
possible that both physical representations will cohabit the same system. This last 
possibility is especially important in distributed systems where the autonomy of nodes on 
the network must be respected. 


II. 2 


Descriptions of Communications 


Messages are sent to guardians in communications. A request is a communication 
which alwavs contains a message and a customer: 


(a Request) is 

(n 


{a Request [message: (a Message)] [customer: (a Customer)])) 

The concept of a customer generalizes the notion of a continuation in the lambda calculus 
programming languages (A. Church, C. Strachey, L. Morris, C. Wadsworth, J. Reynolds, C. 
Hewitt, Sussman and Steele, etc.]. When an actor receives a message M and customer c, it 
has the right to negotiate with c for the funds necessary to process the message M. This 
negotiation process implements the notion of bankers proposed in [Hewitt, Bishop, and 
Steiger: 1973], Eventually the customer C should be sent a Response which is either a Reply 

or Complaint for the message M. 
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; Another kind of communication is a Response which is either a reply or a 
complaint: 

(3 Response) is 

*• * v * * * • 

(a Communication) and 

(0 ; \ 

(a Reply [message: (a Message)]) 

(a Complaint [message: (a Message)])) 

1 . . * ’ ’ 

\ 

III - PRIMITIVE SERIALIZERS 

The design goals for monitors is that they were intended to be a structuring 
construct for implementing operating systems. There have been some attempts to develop 
useful proof rules for monitors [Howard; 1976; Gjessing; 1977; Hoare: 1974; Owicki; 1978] 
Serializers [Atkinson and Hewitt: 1977, 1979] are a further step toward these goals. 
However the language construct developed by Hewitt and Atkinson may be too complicated 
to be useful both as a formal foundation and as a basis for the proof methodology. In the 
study we present here the approach has been reversed. Instead of designing a desirable set 
of primitives and then trying to describe their semantics in a formal w r ay, we started with a 
basic primitive with a simple semantics. 

The syntax of a simple primitive serializer in Actl is; 

( create_serialized_actor B) 

A primitive serializer can be used to create an actor S whose behavior can change 
as a result of the communication which it receives. At any given time S is either locked 
or unlocked. It has a current behavior (which is another actor). When S is created it is 
unlocked. When the first communication arrives, the serializer becomes locked and the 
communication received is sent to B. 

Executing a command of the form 

{Uan$mit_to tc) 

will result in the transmission of the communication actor c to the target actor t. 
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In addition to possibly transmitting some communications, B computes a new 
behavior NB using a command of the form 

{become NB) 

The actor NB is installed as the next behavior of S. The actor S then becomes unlocked 
and thus able to accept the next message. An important consideration in the design of 
efficient serializers is that they should remain locked for as brief a time as possible. 

A behavior will typically be implemented using create_unserialized_actor expression 
which has the following syntax: 

( create_un$enalized_actor 

( pattern_for_communicalion | received body j) 

<pat°om t i on j f eceived bod/j)) 

If an actor created by a create_un$erialized_actor expression receives a communication C 
which matches any of the patternjor_communicationi , then the corresponding body; is executed 
to produce the next behavior. If C matches more than one of the p attem_<or_communication ; , 
then an arbitrary one of the corresponding bodyj is selected to be executed. 

■1 - : ■ , .. ._ 

Note that there are three separate events which must occur before a 

communication C can be accepted by a serialized actor T. First it must be transmitted in 
a transmission event of the form 

(a Transmission [target: T] [communications CJ) 

Next it must arrive in an arrival event of the form 


{an Arrival [target: TJ [communication: CJ) 


Hardware modules called 
communications sent to T. 
form 


arbiters are used to establish an arrival ordering for all 
Finally it must be accepted in an acceptance event of the 


{an Acceptance [recipient: T] [communication: <y) 

H '■ ‘ , ' l 

Communications are accepted in the order in which they arrive. The acceptance marks a 
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transition in which the target changes from unlocked to locked. Thus if a serialized actor 
becomes locked then no more messages can be accepted until it unlocks. 


IV - A SIMPLE EXAMPLE 


IV. 1 —- Descriptions of Messages for Checking Account 

As a simple example of how primitive serializers can be used, we give the 
implementation of a very simple checking account guardian. 

There are two kinds of messages which must be dealt with by the guardian 
Withdrawal and Deposit which can be described as follows: 

(a Withdrawal) is 

(a Message) and 

(a Withdrawal [amount: (a Non - .negative_US_currency)]) 

t 

(a Deposit) i$ 

(a Message) and 

(a Deposit [amount: (a Nonjiegative_U$_currency)]) 

which says that both kinds of messages have an attribute named amount which must be a 
non-negative'US currency. 

(a Transaction_completed_report) i$ (a Reply) 

(a Transaction_not_completed [reason: overdraft]) IS (a Complaint) 

IV.2 — A Concurrent Case Expression 

Clearly some kind of conditional test is needed in implementations. Use will be 
made of select_ca$e_for expressions of the following form: 




[select_ca$e_for expr ession 
( pattern ^ produces body ^ 

• • * 

( pattern^ produces body n ) 
[none_of_the_above: alternative_body] ) 


i 
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which when evaluated first evaluates expression to produce a value V If the value V matches 
any of the pattern then the corresponding body ; is executed and its value is the value of the 
select_ca$e_for expression. If the value V matches more than one of the pattern then an 
arbitrary one of the corresponding body ; is selected to be executed. This rule has the 
advantage that it makes bod^ more modular since it depends only on pattern; , making it 
easy to add more selections later. Thus the rule of concurrent consideration of cases 
encourages the construction of programs which are more modifiable. The programs are 
also more robust since the addition of new cases is less likely to introduce bugs in already 
existing cases. 

We shall say that two activities are concurrent if it is possible for them to occur at 
the same. The concurrent case statement facilitates efficient implementation by allowing 
concurrent matching of expression against the patterns. This ability is important in 
applications where a large amount of time is required to determine whether or not 
conditions hold. Thus the rule of concurrent consideration of cases enables some programs 
to be implemented more efficiently. 

If the value V does not match any of the pattern ; then altemative_body is executed. 
This rule provides the ability to have the patterns represent special cases leaving the 
alternative Jjody to deal with the general case if none of the special cases apply. 


IV. 3 — A Simple Guardian 

In this section we present an implementation of a checking account guardian'which 
guards a checking account to ensure that timing errors do when concurrent attempts are 
made to deposit or withdraw money. An implementation of the checking account guardian 

is given below: 

(describe (create_account [initial_balance: =i (a Non_negativeJJS_currency)]) 

[is: (a Serialized_actor [respondsJo: (l!) (a Deposit) (a Withdrawal))])] 

;responses to deposit and withdrawal messages are guaranteed 
[implementation: 

(area te_serialized_ac tor 

{an Account [balance: i]))]) 

4 

The behavior of an Account is defined below: 
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{describe (an Account [balance: (3 Non_negative_US_currency)]) 

[implementation: 

{ create r _unseriaiized_actor 

((a Request [message: (a Withdrawal [amount: =a])] [customer: =c]) received 
(seiect_case_for balance 
((> a) produces 

(transmit_to t (a Transaction_completed_report)) 

(become (an Account [balance: (balance - a)]))) 

(« a) produces 

(tran$mit_to e (a Transaction_nol_completed [reason: overdraft]))))) 

((a Request [message: (a Deposit [amount: =d])] [customer: =c]) received 
(transmit_to t (a Transadion_completed_report)) 

(become (an Account [balance: (balance + d)]))))]) 

V - IMPLEMENTING A HARDCOPY SERVER 


Implementing a hardcopy server on a distributed system provides a concrete 
example to illustrate the advantages of primitive serializers. The following definition shows 
a program to create a guardian for two hardcopy devices. The example illustrates how a 
primitive serializer can be used to implement a guardian that protects more than one 
resource. Finally, the program below illustrates the use of nondeterminism in primitive 
serializers since if both devices are idle, then a nondeterininistic choice is made which 
should serve the next Hardcopy_request since it doesn't matter which one is chosen. 


V. 1 — A Concurrent Conditional Expression 

i ■ ■ . 

* 

* t . * . ^ ■ . • 

The implementation of the hardcopy server given below makes use of a conditional 
construct of the following form: 

( select_one_of 

(if condition ^ then body <) 

• f • 

(if condition^ then body n ) 

[r>one_of_lhe_above: alt ernalive.bod y]) 

If any conditiort j holds then the corresponding bodyj is executed. If more than one of 
the condition; hold then an arbitrary one of the corresponding body} is selected to be 
executed. The user will be warned if more than one of the condition} can hold 








12 


Guardians 


simultaneously and the execution of the corresponding bodyj do not have equivalent effects. 
The rule of concurrent consideration of conditions encourages programs which are more 
robust, modular, easily modifiable, and efficient than is possible with the conditional 
expression in LISP for the reasons which are enumerated in the discussion of the 
se!ect_ca$e__for expression. If none of the condition) hold then alternative_body is executed. 


The reader will probably have noticed that the $elect_one_of construct is very 
similar to the seiect_case_for construct which we introduced earlier in this paper. The 
reason for introducing both constructs is that whereas the $elect_ca$e_for construct is 
often quite succinct and readable there are cases such as the implementation below in 
which it is desirable to concurrently test properties of more than one actor in a single 
conditional expression making the use of select_one_of preferable 


The select_one__of expression is different from the conditionals of McCarthy, 
Dijkstra, etc, in several important respects. The conditions of $elect_one_of have been 
generalized to allow pattern matching as in the pattern directed programming languages 
PLANNER, QA-4, POPLER, CONNIVER, etc. Notice that our concurrent conditional 
expression is different from the usual nondeterministic conditional in that if any of the 
conditions hold then the body of one of them tnust be selected for execution even if the 
evaluation of some other condition does not terminate (cf. [Manna and McCarthy: 1970, 
Paterson and Hewitt; 1971, Friedman and Wise: 1978]). 


V. 2 1 — Implementation of a Hardcopy Server 

Below we give the implementation of the hard copy server. 
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{describe (create.hardcopy.server =device^ =device 2 ) 

[is: (a Serialized.actor 

[responds.to: (a Print_request5] 

[accepts: 

(0 

(a Completion [device: (t!j device^ device^)]) 

(a Breakdown.report [device: (0 device^ device 2 )]))])] 

[implementation: 

(label the.hardcopy.server .the.hardcopy .server is the name of the actor created by serialize 

( create_$enalized_actor 

(a Hard.copy.server [queue: (an Empty.queue)] [device.statej: idle] [device.stateo: idle])) 
where ;the following is lexically nested in the above 


(describe (a Hard.copy.server [queue: (a Queue [each.element: (a Print.request)])] 

[device.state j: (£j idle printing broken)] 

[devicej5tate2: (0 idle printing broken)]) 

[preconditions: (implies 

(queue is -i(a Queue [sequence: []])) 

(and (device.statej 1$ -lidle) (device„stat ©2 i$ -'•idle)))] 


[implementation: 

( create_un$eria!ized_actor 
((a Print.request) =the_request received 

(ponder (a Hardcopy .server [queue: (a Queue [all.but.rear: queue] [rear: the.reque$t])]))) 
;invoke the ponder transition with the.request at the rear of the queue 


((a Completion [device: device = j] [response: =r] [customer: =c]) received 

;this communication notifies the serializer that device = j has completed printing 
;the value returned by that operation is r and was expected by c 

(tran$mit_to c r) 

(ponder (a Hardcopy.server [device.statej: idle]))) 


((a Breakdown.report [request: =r] [device: device.j]) received 
(ponder (a Hardcopy.server 

[queue: (a Queue [front: r] [all.but.front: queue])] 
[device.stateji broken]))))]))]) 
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We have adopted in this code and in our language a useful convention for giving 
default values to missing attributions in a description. For instance in the above code the 

expression 

{& Hardcopy_$erver [queues (d Queue [aiLbutj'ear: queue] [rears the^request])]) 

i . 

is considered to be equivalent to 

« 

(a Hardcopy ..server 

[queue: (a Queue [aiLbutj'ear: queue] [rear: thej'equest])] 

[device^statedevice^statej] 

, [device_state2J device^state^]) 

This convention allows us to shorten our notation by avoiding the repetition of all the 
attributions that are left unchanged. 

Below we define the function ponder which maps behaviors onto behaviors: 

( describe (ponder (a Hardcopy .server 

[queue: (a Queue [each.element: (a Print_request)])] 

[device.statej: (CJ idle printing broken)] 

[device_state 2 : (Cl idle printing broken)])) 

[is: (a Hard.copy.server)] 

[implementation: 

{select_one_of 

{if (queue i$ (a Queue [front: (a Request [message: =r] [customer: =c])] 

[all.butjront: =all_but_front_q])) 

and (device_state ( _j whichJs (Cl 1 2)) I s id,e) 

then 

{tran$mit_to devicoj 

(a Request [message: r] 

[customer: (create^transactionjeanager 

[request: rj 
[device: devicej] 

[customer: c])])) 

(become (3 Hard„,copy„server [queue: aii_but JronLq] [device^statej: printing]))) 

(/Hdevice.statej is broken) and (device_state 2 /S broken) then 
(fra/lsm/f_fo operator "Both printers are broken!") 

( become (a Hard.copy.server))) 

[none.of.the.above: 

( become (a Hard.copy.server))])]) 
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Note that a new transaction manager is created to manage each printing request 
for the hardcopy device. 

The actor createjransadion_manager (defined below) creates a serialized actor s 
wrapped inside a time_out_if_no_re$ponse_dfter expression: 

(time_outJf_no_response_after (10 minutes) 

S) 

which forwards to s any message it receives and also sends s a Time.out message after 10 

minutes if it has not received a response in the meantime. Requests for more funding are 

not considered to be responses and are passed through to s. Of course if the time-out 

expires after a response has been forward to s, then $ is not bothered with a Time out 
message. 

Note that if a manager receives a Time_out message then it sends the hardcopy 

device an abort_ P riniing message waiting 1 minute for the device to respond using the 
following expression: 

( $end__to d abort_printing [time_out_if_no_response_after: (1 minute)]) 

If the device responds with a Ready_for_next_request_re P ort within 1 minute then 
the_hardcopy_server is told that the transaction has completed with a response which is a 
complaint that the allotted time has been exceeded. If the device does not respond to an 
abort_printing message within l minute, then »he_hard_co Py server is sent a breakdown report 
for the device and the operator is informed that the device is broken. 

The definitions given below are assumed to be inside the lexical scope of the above 
serializer thus making the_hardcopy_server lexically visible. 
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{describe (create_transaction_manager [request: =r] [device: =d] [customer: =c]) 

[is: (a Serialized_actor [accepts: (t!j (a Response) (a Time.out))])] 

[implementation: {create_serialized_actor (a Transaction.manager [timed.out: false]))]) 

(describe (a Transaction_manager [timed_out: (a Boolean)]) 

[implementation: 

(time_out_if_no_response_after (10 minutes) 

(create_unserialized_actor 

((a Response) ==the_response received 
{if {not timed_out) 

then {transmit_to Ahejnardcopy .server 

(a Completion 
[device: d] 

[response: the_response] 

, [customer: c]))) 

{become (a Transaction_manager))) 

((a Time_out) received 

{select_case_for {send_to d {an AborLprinting_request) 

[time_outJf_no_response_after: (1 minute)]) 

((a ReadyJor_next_request_report) produces 
( tran$mit_to the_hardcopy.server 
(a Completion 

[device: d] 

[response: (a Complaint [message: allotted_time_exceeded])] 

[customer: c])) 

(become (a Transactionjnanagor [timed_out: true]))) 

((a Time_out) produces 

(transmit_to operator (a Breakdown_report [device: d])) 

(transmit_to the_hardcopy_server (a BreaKdown_report [request: r] [device: d])) 
(become (a Transactionjrvanager [timed.out: true])))))))]) 

The statement • 

(become (a Transaciion„manager [timed_out: true])) 

has the effect of causing the timed_out state component of the transaction manager to 
become true. Therefore any response addressed to that actor after its termination will be 

discarded since the code specifies 
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* * ^ t 

Of (not timed_out) 

then (transmit_to the_hardcopy_server 

(a Completion 

[response: the_response] 

[device: d] 

[customer: c]))) 

(become (a Transaclion_manager)) 


In particular a response form a device will not he considered after a time_out has been 
generated. 


VI - PARTIAL SPECIFICATIONS OF A HARD-COPY SERVER 


Using primitive serializers, we have been able to deal with an important problem in 
the specification of guardians which allow time out. The problem is that if a guardian is 
allowed the possibility of time out in a partial specification how is it possible to rule out a 
trivial implementation which always times out. Our solution to this specification problem is 
to require that a guardian which receives a Print_request PR which satisfies the following 
description; 


(a Print_request 

[message: PR] 
[customer: C]) 


must eventually send one of the hardcopy devices a communication which satisfies the 
description 


(a Request 

[message: PR] 

[customer: M]) 

where M is a transaction manager. Furthermore if M receives a response before it receives 
a time out message then the response must be sent to C. 

This specification forces the hard copy server to at least try to satisfy the print 
request PR. It cannot simply wait 10 minutes and then transmit a time-out complaint to 
the customer C. 
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VII - PROOFS FOR THE HARD-COPY SERVER 

The proofs here assume that if both printing devices break down then at least one 
of them will eventually be revived by the operators. 

We first show that the preconditions on the behavior of the hard-copy server are 
always met These preconditions are useful in the rest of the proof. 

The second part of the proof shows that the serializer completes each transition 
from a state in which it is unlocked to a state in which it is again unlocked. This will be 
a preliminary result for proving that the preconditions for the hard-copy server always hold. 
Finally we prove that the guardian always replies to the requests which it receives. 


VII. 1 — Checking the Preconditions of the Behavior 

First we verify that the preconditions on the behavior of the hard-copy server 
always hold, namely- 

(queue/$ (3 Queue [each_element: (a PrinLrequest)])) 

(devke.statej i$ (l!j idle printing broken)) 

(device. state 2 i$ (l!l idle printing broken)) 

The proof that these preconditions always hold is by induction. 


1. Show that the preconditions are met when the hard-copy server is created. 

2. Assuming that the preconditions are true, show that, whatever communication is 
received, the next become statement will produce a hard-copy server which meets the 
preconditions. 


It is clear by inspection that each of the three preconditions is true when the 
serializer is created. After a communication is received, the function ponder is called with 
arguments satisfying the preconditions in creation of a behavior for ponder. This description 
can be used and gives us the fact we needed to complete the proof. Now to show that the 
implementation of ponder corresponds to its description, a similar technique can be used. In 
this proof we will have to use the descriptions for the operations called by ponder. 


This part of the proof is not very different from the kind of static type checking 
usually performed by a compiler. 
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VII.2 — Proof of the Preconditions 

We want to show that whenever the guardian is unlocked, its state satisfies the 
precondition: 

(implies 

(queue J$ ~>(an Empty_queue)) 

(and (deviee_statej IS *-»idle) (device_stat ©2 is -»id!e))) 

It is immediate that this precondition holds vacuously at the creation of the 
hard-cbpy server since the queue is empty. 

The general result can be established by case analysis for each communication 
received. For instance if the guardian receives a Printj-equest r in a state where the receipt 
preconditions hold, then the request r will be added to the rear of the queue and ponder 
will be called with a . non empty queue as an argument There are two cases to be 
considered (we are assuming the absence of breakdowns): 

1: One of the devices is idle. Therefore by the 

precondition the queue contains only the request r. The request r 
is removed from the queue and the appropriate message is sent to 
the idle device. This reestablishes the precondition because the 
queue is once again empty. 

2: None of the conditions in the ponder transition is true, 
so that the none_ofJhe_above clause applies. Since the queue was 
not empty, this means that none of the devices was idle. Then 
the guardian unlocks becoming a hard-copy server with the state 
of both devices being not idle. Therefore the precondition will 
hold again also in this case. 

The proof that the receipt preconditions hold when the guardian is unlocked is 
similar for the Completion communications and the Breakdown_report communications. 
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VII. 3 — Proof of Guarantee of Service 

We can prove that service is guaranteed to all printing requests. If the guardian 
receives a request when one of the devices is idle, the request will be immediately passed 
on, since the queue will be empty according to the precondition for the hard-copy server. 

If none of the devices is idle, then the request will be queued. 

The following assertion is proved by induction on n: 

If n requests precede a request R in the queue, then R will be 
passed to one of the devices after n completion communications have 
been received by the guardian. 


A completion is either one of the following communications: 


(a Completion [device: device^] [response: ...] [customer: ...]) 

(a Completion [device: device 2 ] [response: ...] [customer: ...]) 

* 

The implementation of the guardian has the property that the hardcopy server will always 
receive a communication back for each of the requests it sent to a device. By the 
precondition for the hard-copy server we know if R is in the queue, then there is a request 
outstanding for cither device^ or device 2 , and a completion or a breakdown report will be 
received by the guardian. 


The first such communication will be received after a number p of print requests 
have been received by the guardian, p is finite because of the law of finite chains in the 
arrival ordering of actor systems [Hewitt and Baker 1977]. 


We can show that each of these p print request will leave unchanged the first n 
elements in the queue and will not alter the state of the devices. Consider then the effect 
of the next completion received by the guardian. We show that either the number of 
requests preceding R is decreased by one in the next unlocked state or the request R is 
sent to one of the printing devices. Clearly one effect of the completion is that one of the 
devices will become idle. Therefore the next request will be removed from the queue and 
passed to the free device. Therefore if n is 0, the request R is served. On the other hand 
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if n is bigger then 0, then removing the first element from the queue reduces by one the 
number of elements preceding R in the queue. 


VIII ~ ADVANTAGES OF PRIMITIVE SERIALIZERS 

We would like to discuss some of their advantages over previous proposals for 
language constructs for synchronization. 

VIII. 1 —- Control Flow follows Text 


Each activity of the serializer is initiated by the receipt of a communication which 
causes the serializer to become locked. After a new receiver has been computed, it 
becomes unlocked and is ready to receive another communication. Unlike monitors, 
serializers have no explicit wait or signal command which cause the execution to be 
suspended and resumed from different points within the program. 



VIII. 2 — Absolute Containment 


Primitive serializers make it easy to implement guardians which do not give out the 
resources being protected. Instead a guardians passes messages from the users to the 


resources implementing a property which we call absolute containment which was proposed 
by [Hewitt: 1975] and further developed in [Hewitt and Atkinson; 1977] and [Atkinson and 
Hewitt; 1979] (cf. [Hoare: 1976] for a similar idea using the inner construct of SIMULA). 
The idea is to pass a message with directions to the resource so that it can carry out the 
directions instead of giving out the resource to the user. An important problem with the 
usual strategy of giving the resource out is that retrieval of the resource from a process 
that has gone amuck is often messy. 


We have found that absolute containment produces more modular implementations 
than schemes which actually gives out resources protected by guardians. Note that the 
proof that all requests will receive a rc ponse from a network utility that implements 
absolute containment depends only on the behavior of the resource and the code for the 
serializer which implements the guardian, but not on the programs which call the guardian. 
In the usual scheme of giving out the resource, it is necessary to prove that each process 
which can use the resource will give it back. 
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Our hardcopy server implements absolute containment by never passing out either 
of its hardcopy devices to the external environment. Thus there is no way for others to 
depend on the number of physical devices available. Furthermore there is no problem 
retrieving the devices from users who have seized them since they are never given out. 


VIIO — Modularity in State Change 

Primitive serializers directly support a scheduling strategy of receiving each 
communication and then deciding what actions the communication requires. The possible 
actions include changing state and sending messages to other actors. [ 

The only way to cause a state change in the programming language used in this 
paper is to use a primitive serializer. State change can be encapsulated within a serializer 
in a much more modular fashion than is accomplished by individual ASSIGNMENT and 
GOTO commands. In serializers state change and transfer of control are encapsulated in a 
single primitive that accomplishes them concurrently. We have found that this 
encapsulation increases the readability and modularity of implementations that require state 

change. 

VIIL4 — Generality 

In our applications we want to be able to implement guardians which guarantee 
that a response will be sent for each request received. This requirement for a strong 
guarantee of service is the concurrent analogue to the usual requirement in sequential 
programming that subroutines must return values for all legitimate arguments. In our 
applications it would be incorrect to have implementations which did not guarantee to 
respond to messages received. 

The SIMULA subclass mechanism was designed for sequential and quasi-parallel 
programming. It needs substantial revision for concurrent programming. The monitors of 
Hoare and Brinch-IIansen represented a substantial step towards generalizing classes for use 
in concurrent systems. However the use of explicit wait and signal commands on fifo queues 
or priority queues makes the scheduling structure of monitors somewhat inflexible. 
Furthermore it is difficult to prevent deadlock if monitors are nested within monitors. One 
strategy for implementing guardians with monitors is to use an ordinary SIMULA class 
whose procedures invoke a monitor which is local to the class. For example a hardcopy 
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server could be implemented as an ordinary class with a PRINT procedure which invokes 
REQUEST_PRINT, START_PRINT, and STOP.PRINT procedures in the monitor. Primitive serializers 
avoid the two level structure of monitor within class by explicitly dealing with the actors 
which act as customers to whom replies should be sent No special commands like wait and 
signal are needed because the customers are ordinary actors which can be remembered and 
manipulated using the same techniques that work for all actors. 

The utility of the extra generality in primitive serializers is illustrated by our 
implementation of the hardcopy_server in which we place a request which is not serviced 
because of the breakdown of a printer at the front of the queue of requests to be serviced. 
Many synchronization primitives' with more built-in structure (such as monitors) permit 
additions to queues only at the rear. 


VIII. 5 


Conveniently Engendering Parallelism 


Primitive serializers provide a very convenient method for causing more parallelism: 
simply transmitting more communications. The usual method in other languages for 
creating more parallelism emails creating processes (cf. ALGOL-68, PL-1, Communicating 
Sequential Processes etc.). The ability to engender parallelism by transmitting 
communications is one of the principle differences between actors and the usual processes in 
other languages. For example in the implementation of the transaction manager in this 
paper, both the operator and the_hardcopy_server can be notified that a printer has broken 
down by simply transmitting the appropriate communications. 


VIII.6 — Unsynchronized Communcation 

In actor systems it is not necessary to know whether the intended recipient is ready 
to receive the communication; a guardian implemented using primitive serializers can 
transmit communications and then receive more messages before the communications which 
it has transmitted have been received. In our application involving the implementation of a 
distributed electronic office system, it is highly desirable that the sending of communication 
be unsynchronized from the receipt of the communication. 
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VIII. 7 


Behavior Mathematically Defined 


The behavior of primitive serializers can be read directly from the code. These 
mathematical denotations are intended provide a solid mathematical foundation on which to 
develop proof techniques and to provide a direct link with the underlying actor model of 
computation. Mathematical denotations have not yet been developed for the serializers in 
[Hewitt and Atkinson: 1977] or monitors because of the complexity of these constructs. 


VIII. 8 — Encouraging the use of Concurrency 

Primitive serializers permit implementations to use near maximum concurrency. In 
particular in contrast to the usual process model which only allows sequential execution 
within a monitor or critical region, primitive serializers encourage the use of concurrency in 
handling messages received. The only limitation on parallelism in systems constructed using 
ACT! derives from communications received by serialized actors when they are locked. 


VIII. 9 


Absence of Deadlock 


Primitive serializers have the important advantage that it is possible to guarantee 
absence of deadlock in actor systems by simply assuring that each individual actor will 
unlock after it receives a message. Absence of starvation (e.g. that every request received 
will generate a response) is more difficult to prove. 


VIIL10 — Ease of Proof 

We have found the above advantages of primitive serializers quite helpful in proving 
properties of implementations. Furthermore the structure of our proofs follows naturally 
from the syntactic structure of a primitive serializer. The proof given in this paper that 
the hardcopy' server will always respond to requests which it receives illustrates how 

primitive serializers facilitate proofs. 
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IX - FUTURE WORK 

W 7 e are encouraged with the experience of using our description system to describe 
each of the programming problems considered in this paper. However it clearly needs 
much further development in pragmatic and behavioral descriptive power. 


One important area in which work remains to be done is to demonstrate that 
primitive serializers can be implemented as efficiently as other synchronization primitives as 
semaphores, monitors, etc. We have designed primitive serializers with this goal in mind. 
On the basis of some preliminary investigation we believe that they can be implemented at 
least as efficiently as monitors and communicating sequential processes. The third author 
has constructed some preliminary implementations in a dialect of the ACT1 language 
described in this paper which runs on the PDP-10. In the course of the next year, we will 
continue to work to improve this implementation and to transfer it to the MIT CADR 
machine where ultimately it can be supported by micro-code. 


Another area in which work remains to be done is automating proofs such as the 
one in this paper. We feel that we are getting close to the point where a Programming 
Apprentice can do most of such proofs under the guidance of expert programmers. Russ 
Atkinson is working on automating the proofs for the version of serializers in [Atkinson 
and Hewitt: 1977] and [Hewitt and Atkinson; 1979], We hope to be able to use some of 
the techniques which he has developed in our symbolic evaluator. 
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X ~ CONCLUSIONS 

We are encouraged with our initial experience in working with primitive serializers 
and plan to develop them further. They appear have a number of important advantages 
over previous proposals for modular synchronization primitives. These advantages include 
ability to delegate communications [Hewitt, Attardi and Lieberman: 1978] and compatibility 
with the implementation of unserialized actors [Hewitt 1978]. Event oriented specification 
and proof techniques are readily adapted to proving properties of guardians implemented 
using primitive serializers. These properties include the guarantee that a response is sent 
for each request received and a guarantee of parallelism [Atkinson and Hew'itt- 1978]. 
Note that the property of guaranteed response for each message sent cannot be proved in 
many models of computation because it implies the possibility of unbounded 
nondeterminism [Hewitt: 1978]. In this paper we have shown how previous work on event 
oriented specifications and proofs can be extended to deal with time outs. 

Partial descriptions like the ones given in this paper are illegal in almost all type 
systems. The desire to be able make incremental multiple descriptions such as these has 
been one of the driving forces in the evolution of our description system. The SIMULA 
subclass mechanism is probably the most flexible and powerful type mechanism in any 
widely available programming language. However, as a description system, it has some 
important limitations. It does not support interdependent descriptions or multiple 
descriptions. Also it does not permit instance descriptions to be qualified with attributions. 
Furthermore it does not permit descriptions to be further described thus disallowing any 
possibility of incremental description. 
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concurrency as the core of the language. It was developed in an attempt to synthesize a 
unified system that combined the message passing, pattern matching, and pattern directed 
invocation and retrieval in PLANNER [Hewitt: 1969; Sussman, Charniak, and Winograd; 
1971; Hewitt: 1971], the modularity of SIMULA [Birtwistle et. at.: 1973, Palme- 1973], the 
message passing ideas of [Kay: 1972], the functional data structures in the lambda calculus 
based programming languages, the concept of concurrent events from Petri Nets (although 
the actor notion of an event is rather different than Petri's), and the protection inherent in 
the protected entry points of capability based operating systems. The subclass concept 
originated in [Dahl and Nygaard: 1968] and adapted in [Ingalls: 1978] has provided useful 
ideas. 

The pattern matching implemented in PLASMA was developed partly to provide a 
convenient efficient method for an actor implemented in the language to bind the 
components of a message which it receives. This decision was based on experience using 
message passing for pattern directed invocation which originated in PLANNER [Hewitts 
IJCAI 69] (implemented as MICRO-PLANNER by [Charniak, Sussman, and Winograd: 
1971]). A related kind of simple pattern matching has also be used to select the 
components of messages by [Ingalls: 1978] and by [Hoare: 1978] in a design for 
Communicating Sequential Processes. However CSP uses assignment to pattern variables 
instead of binding which was used in PLANNER, SIMULA, and PLASMA. 
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APPENDIX I — Implementation of Cells using Serializers 

In this appendix we present an implementation of cells [Greif and Hewitt 
POPL-75, Hewitt and Baker: IFIP-77] using primitive serializers. 

(describe (create.cell =initiaLcontents) 

[is: (a $erialized_actor [respondsJo: (ft (a Content$_query) (a/7 Update))])] 

[implementation: 

( create_$eria!ized_actor 

(a Cell [current_contents: initiaLcontents]))]) 

(describe (a Cell [currenLcontents: (an Actor)]) 

[implementation: 

( create_un$erialized_actor 

((a Request [message: contents?] [customer: =c]) received 
(tran$mit_to c (a Reply [message: currenLcontents]))) 

;reply sending to the customer the current contents 

;unlock the serializer for the next message without changing the behavior 

((an Update [nexLcontents: =n]) received 

(tran$mit_to c (a Reply [message: (an Updatejp>erformed_report)])) 

(become (a Cell [currenLcontents: n]))))]) 

;unlock the serializer with the current contents being n 

The above definition shows how serializers subsume the ability of cells to efficiently 
implement synchronization and state change in concurrent systems. 
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APPENDIX II — Implementation of Semaphores using Serializers 


Semaphores are an unstructured synchronization primitive that are used in the 
implementation of some systems. The definition below shows how primitive serializers can 
be used to efficiently implement semaphores. 


(i describe (create. 


semaphore) 


[is: (a Serialized_actor 

[accepts: (l*J (a Request [message: P]) (a Request [message: V]))])] 
[implementation: 

(create _$eriaiized_actor 

(a Semaphore 

[queue: (an Empty..queue)] ;imtinlly there are no waiting P requests 
[capacity:!]))]) ;the capacity in initially 1 


(describe (a Semaphore 

[queue: (a Queue [each^element: (a Customer)])] 

[capacity: (a Nonjiegative jnteger)]) 

[preconditions: 

(implies 

(queue i$ -» (an Empty„queue)) 

(capacity is 0))] 

[implementation: 

, i 

(create_un$erialized_actor 

((a Request [message: P] [customer: =c]) received 

($elect_ca$e_for capacity ■ 

((> 0) produces 

{transmit_to c [reply: (a Completed_P_report)J) 

(become (a Semaphore [capacity: (capacity - 1)]))) 

(0 produces (become (a Semaphore [queue: (queue enqueue c)]))») 

* 

;hecome a semaphore with c enqueued at the rear of queue 


((a Request [message: V] [customer: =c]) received 
(transmits0 c [reply: (a Completed^report)]) 

(seiect_case_for queue 

((a Queue [front: =c] [alLbutJront: =resLwaiting_customers]) produces 
(transmit^to c [reply: (a Completed_Pj'eport)]) 

(become (a Semaphore [queue: resLwaiting^customers]))) 

((an Empty^queue) produces 

(become (a Semaphore [capacity: (capacity + !)]))))))]) 


In [Hoare: 1975] there is an elegant construction showing that monitors can be implemented 
using semaphores and cells. His technique can be adapted to show that primitive serializers 
can also be implemented using semaphores and cells. 
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APPENDIX III — Thumbnail Sketch of the Description System 

This appendix presents a brief sketch of the syntax and semantics of our description 
system. A paper which more fully presents the description system and compares it with 
other formalisms which have been proposed is in preparation. 


The description system is intended to be used as a language of communication with 
the proposed Programming Apprentice. Its syntax looks somewhat like a version of 
template English [Hewitt: 1975, Bobrow and Winograd: 1977, Wilks: 1976] Thus for 
example we write (an Integer) in this paper instead of writing (integer) as was done in 
PLANNER-71. However we also allow the use of instance descriptions such as 
(the Integer [>: o] [c 2]) to describe the Integer which is greater than 0 and less than 2. 

We feel that it is quite important that a description expressed in template English 
correspond in a natural way with the intuitive English meaning. For this reason we use 
the indefinite article in attribute descriptions such as the one below: 

(4 is (an element of {2 4 6})) 


where the binary relation element can occur multiply in an instance description such as 

(({2 4 6} IS (a Set [element: 2] [element: 4]))) 

Note that (a Set [element: 2] [element: 4]) is a partial description of {2 4 6}. Attribute 
descriptions only make use of the definite article in cases like the one below 


((the imaginary_part of (a Real)) i$0) 

where the binary relation imaginary_part projectively selects the imaginary part of a Real. In 

this case the relation imaginary^part might be inherited from Complex via the following 
description: 


((a Real) is (a Complex [imaginary.part: 0])) 

* 

i • 

: ’ ■■ ^ . - *, ::-tr ■ »' ■ 

For the purpose of describing mappings, I prefer the syntax 


[=X*—> ...X...J 

• i 


[cf. Bourbaki: Book I, Chapter II, Section 3] to the syntax 
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\A x# m.x.u) 

* - * 

of the lambda calculus. For example the mapping cubes which takes a number to its cube 
can be described as follows: 

{describe cubes 
[is: [=ni —> n^]]) 

XII. 1 — Examples 

XII. l.a —- Articulation 

Articulation is an important capability of a description system. For example 

{describe cubes 

[is: (a Mapping [=nt~> n^])]) 

can be articulated as follows; 

(cubes is (a Mapping [l 1 —* 1] [2*—* 8] [3*- > 27] [4* ^ 64] [5< ^ 125] ... )) 
where ... is ellipsis 

■„ • • ' 1 ■ 4 * 

XILl.b -- Sets and Multisets 

Sets and multisets can be described in terms of mappings using the usual 
mathematical isomorphisms. For example 

(describe {a b] 

[is: (a Mapping [a*—> 1] [b'—> 1] [->a (1 -ib 1 * 0])]) 

describes the set {a b} as a mapping front a and b onto 1 since they are present in the set 
and everything else maps to 0 since there are no occurrences of other elements. Extending 
the same idea to multisets gives the following example: 
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{describe {|a b a|} 

[is: (a Mapping [a'—> 2] [b>—> 1] [-,a H -tbi—> 0])]) 

which says that {|a b a|) can be viewed as a mapping in which a occurs with multiplicity 2, b 
occurs with multiplicity l, and all other elements occur with multiplicity 0. 

» - ' 

XILl.c — Transitive Relations 


that 


If (3 is {an Integer [<: 4])) and (4 is {an Integer [<: 5])), we can immediately conclude 
(3 is {an Integer [<: {an Integer [<: 5])])) 


by the transitivity of predication, 
conclude that (3 is {an Integer [o 5])). 


From this last statement, w r e would like to be able to 
This goal can be accomplished by the command 


{describe < 

[is: (a Transitive_relation [for: Integer])]) 


which says that < is a transitive relation for Integer and by the command below which says 
that if x is an instance of a concept which has a relationship R with something which is the 
same concept which has the relationship R with m where R is a transitive relationship for 
concept, then x has the relationship R with m. 


{describe {a ^concept [=R: {a =concept [=R: =m])]) 

[preconditions: (R is (a Transitive_relation [for: concept]))] 
[is: (a concept [R: m])]) 


The desired conclusion can be reached by using the above description with concept bound to 
Integer, R bound to <, and m bound to 5. 
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XILl.d — Projective Relations 

If (z is (a Complex [real_part: (> G)])) and (z IS (a Complex [real_part: (an Integer)])) then by 
merging it follows that (z is (a Complex [real_part: (> 0)] [real_part: (an Integer)))) However in 
order to be able to conclude that (z is (a Complex [real_part: (> 0) (an Integer)])) some additional 
information is needed. One very general way to provide this information is by 

(describe realjpart 

[is: (a Projective..relation [concept: Complex])]) 

and by the command 

e» 

(describe is ~C [~.R: -descriptionl] [~R: ~do$cription2}) 

[pr^conditions: (R IS (3 Projoctive_rolation [concept: C])}] j 

[fa: (aC [R: description! der>cription2])]) S 


The desired conclusion is reached by using the above description with C bound to Complex, R 
bound to real_part, description! bound to {> 0), and descriplion2 bound to (an Integer). 


This example cannot be done in most type systems; the above solution makes use 
of the «-order capabilities of our description system. 


XII. l.e — Self Description 

» *■ 

Self description provides the ability for the programming Apprentice to reason 
about its own procedures. However we must beware of paradoxes. For example the 
following sentence clearly holds in « order logic: 

VP Vx (P x) if_and_only_if (P x) 

From the above sentence, we obtain the following by the usual rules for quantifiers: 

vp 3Q Vx (Q x) if_and_only_if (P x) 

Substituting the following mapping 

<=s i--> ( not (s $))) 
for P, we get 
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a .. 

\ ; 

V . 

3Q Vx (Q x) if_and_only_if (not (x x)) 

Using 3-elitnination with Q 0 for Q we get 

Vx (Qq x) if_and_only_if (not (x x)) 

. * * - * . 

Substituting Q 0 for x we obtain Russell’s paradoxical formula: 

(Q 0 Q 0 )if_and_only_if(not (Q 0 Q 0 )) 

However the above formula is a contradiction in our description system only if 
<Q 0 Qo> is a Boolean which are described as follows: 

(describe (a Boolean) 

[is: (Li true false)]) 

(describe true 
[is: 

•ifalse 

(a Boolean)]) 

(describe false 
[is: 

itrue 

(d Boolean)]) 

We propose to restrict the rules of logic to statements which are Boolean. For example the 
rule of double negation elimination can be expressed as follows: 

(describe (not (not =p)) 

[precondition: (p is (a Boolean))] 

[is: p]) 

In this way we hope to avoid contradictions in our description system. In the course of 
the next year we will attempt to adapt one of the standard proofs to demonstrate its 
consistency. 
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XII. 2 — Axioms 

The description system is defined by its underlying behavioral semantics. The 
axiomatization given below is significant in that it represents a first attempt to axiomatize a 
description system of the power of the one described here. As far as I know previous to 
the development of this one, similar axiomatizations for FRL, KRL, OWL, MDS, etc. did 
hot exist. 

The most fundamental axiom is Transitivity of Predication which says that for any 

<description 3 > 

Transitivity of Predication 

(i implies 
(and 

(<description^>/s <description 2 >) 

(<descriptiori 2 > /$ <descriptiori 3 >)) 

(<descriptionj> is (description)) 

The descriptions in our system are completely intentional. I.e. the fact that the 
extension of two descriptions is the same does not force the conclusion that the descriptions 
are coreferential. Suppose we . define snarks to be set of all animals which are both 
herbivores and carnivores. Then in Zermelo-Fraenkel set theory it follows that (snarks I cows) 
because the empty set is a subset of every other set From the following statements 

((a Snark) is (a Carnivore)) 

((a Snark) is (a Herbivore)) 

((a Carnivore) is ->(a Herbivore)) 

we can conclude that 

((a Snark) is ->(a Herbivore)) 


by transitivity of predication. Thus we can conclude that nothing is a Snark because 
anything which is a Snark would necessarily be both a Herbivore and not a Herbivore. 
However this does not force the conclusion that 

((a Snark) is (a Cow)) 

Another important axiom is 
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Reflexivity 

(<description> !$ <description>) 

i *' 

which says that every description describes itself. 

. ' . ‘ I . < 

Other important axioms are Commutativity, Deletion, and Merging; 

Commutativity 

((a (description^ (attributions^ <attribution 2 > (attributions 3 > (attribution^) (attributions^)) is 
(a <descriptionj> (attributions^ (attribution^) (attributionsg) (attribution 2 > (attributionse))) 

which says that the order in which attributions of a concept are written is irrelevant Note 

that (attributions) is a string of zero or more elements of category (attribution). 

Deletion 

((a (description^) (attributionsj) (attribution 2 > (attributions 3 >) is 

(a (description^) (attributions^ (attributions 3 >)) 

which says that attributions of a concept can be deleted, and 

Merging 
(implies 
(and 

((description^) is (a (description 2 ) (attributions^))) 

((descriptionj)/S (a (description 2 > (attributions 2 >))) 

{(description^) is (a (description 2 > (attributions(attributions 2 >))) 


which says that attributions of the same concept can be merged. 

Additional axioms* are given below for other descriptive mechanisms; 


Coreference 

((description COref (description 2 >) if_and_only_if 

((description!) <description 2 >) and ((description 2 > i$ (description!)) 


1; We are grateful to Dana Scott,Maria Sitni, and Jerry Barber for helping us to remove 
some bugs from these axioms 
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Criteriality 
(implies 
{and 

({description]) is {the_only {description;]))) 

({description 2 ) is {the^only {description 3 >))) 

({description]) COref {description 2 ))) 



Constrained Description 

({description]) is «description 2 > $uch_that {statement))) if_and_only_if 
{implies 

{statement) 

({description]) is {description 2 >)) 

Qualified Description 

({description j) is (<description 2 ) that_IS {description^)) if_and__only_if 
(and 

({description]) is {description 2 )) 

({description]) is {description 3 >)) 

View Point 

(({description j> viewed_8S {description 2 )) is 

■ , ■ «description 2 ) SUCh_that ({description]) is {description 2 ))» 

Shift in Focus 

({description]) is (a {description 2 ) [{descrip?ion 3 >: {description/])])) / f_and_only_if 

({description/]) is (a {description^) of ({description]) viewed_as (a {description 2 >))» 

Definite Selection 

{{the {description]) of (a {description 2 > [{description]): {description^])) is {description^) 

Complementation 

(-.-.{description) coref {description)) 

({description]) is -.{description 2 » if_and_only_if ({description 2 > is -.{description])) 

(({description]) is -i{description 2 >) implies 

(V =d 
* 

(implies 

(d is <description|>) 

(not (d is <description 2 >))))) 
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Meet 

((description^) is (!“1 (description <descriptiori3>)) if^and^onlyjif 

(and 

((description^) i$ (description2>) 

((description^) /S (description)) 

((fl <d©scription^> <d©scription2>)/S <description2>) 

(-i(n (description^) (description2> COKef (U -^(description-i(description2>))) 

Join 

((U <descriptiori2> (description3>) is (description^)) if^and^only^if 
(and 

(<descripfion2> /$ (description^) 

(<descripiion3> is (description^))) 

((descriptionj) /s (U (description^) (descriptknn)) 

(-»(Lj <descripiionj> <description2> (n-*<descrtpSionj>-i<descriptior»2>))) 

Disjoint Join 

((Cl (description j) <d©scription2>) COKef 

(U 

(fl (description^) -i(description2>) 

(il-i<d©scrjptionj> <description2>))) 

Conditional Description 

((description^) i$ (<description2> /f (statement))) if m _and m _only w Jf 
((statement) implies ((description^) i$ (description2>)) 

XII. 3 Syntax 

If (x> is a syntactic category then an expression of the form (x>* will be used to 
denote an arbitrary sequence of zero or more items separated by blanks in the syntactic 

category (x). An expression of the form (x) will be used to denote an arbitrary sequence 
of one or more items separated by blanks in the syntactic category (x>. 

The following is the syntax for descriptions and statements: 
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description) ::= identifier) | 


i 


w. 

=<identifier> | ;the character = i.< used to mark local identifier* 

statement) | ;note that statement* (which are described below) are description* 

attribute ..description) | 
attribution) | 

<instance_description> | 

<criteriaLdescription) | 

<mapping_description) | 

<sequence_description) | 

<set_description> | 

<multiset_description> | 

<instance_description) | 

^description) viewed^dS (description)) | 

^description)//statement)) | 

^description) thatjs description)) | 

(description) such^thdt statement)) | 

(fl description)) | ;D designates the meet of desciptions 

(□description))! ;U designates the join of description* 

(ft description)) | ;ft designates disjoint join of descriptions 
^description) | designates the complement of a description 

(<relation> description)*) 

<criteriaLdescription> (f/)^_on/y <descrip 1 ion>) 

ionly used for descriptions that describe exactly one thin# 

<instance„description) <indefinitejnstance) | definitejnstance) 

indefinite .instance) ::= (<indefinite_article> <concept> <attribution> ) 

<definite_instance> ;:= {the <coneept> attribution)*) 

;de finite instances are used only for criteria l description* 

<indelinite_artic!e> ::= 3 1 an 

;there is no semantic significance attached to the choice of which article is used 
<concept> ::= <description> ;note that this is <0 order 

<attribution> ::= [<binary_rclation_description>: <description>] 

attributions) ::= <attribution>* 

<binary_relation_description> ::= (description) -note that this is (a order 

■ <attribute_description> ::= <projective_attribute_description> | 

(<indefinite_article> <binary_relation_description> of <description>) 
<projective_attribute_description) {thG <binary_relation_description) of (description)) 

•expresses that (binary _relation_description> is projective for Cdescription) 
i*ee example below for mi explanation of pro jective binary relations 
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<mapping_description> ::= [description)*-) description)] 

<sequenc©_description> ::= [<elements_description>*] | 

<set_description> ::= {<elements_description>*} | ;{ and } are used to delimit get* 

* - t 

(multiset_description) ::= {|<elements_description>*|} ;harrcd hracct arc used to delimit multiset% 
(elements_description) ... | 

description) | 

!<description> ,*! it the unpack construct 

• * . ■ 

statement) (<predicate> (description)*) | 

<predication> | 

(<description> COK&f description)) | statement of corcfcrcnce 
({description)*} each^is description)) | 

(and statement)) | 

(or (statement)) | 

(xor statement)) | 

( not statement)) | 

( implies (statement) (statement)) 

(predication) ((subject) is (complement)) 

(subject) (description) 

(complement) 2:= (description) 





